IBIS Macromodel Task Group

Meeting date: 10 June 2014

Members (asterisk for those attending):
Agilent:                    * Fangyi Rao
                            * Radek Biernacki
Altera:                     * David Banas
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
Cadence Design Systems:     * Ambrish Varma
                            * Brad Brim
                            * Kumar Keshavan
                            * Ken Willis
Ericsson:                     Anders Ekholm
Intel:                        Michael Mirmak
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:            Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                              Mike LaBonte
Teraspeed Consulting Group:   Scott McMorrow
                            * Bob Ross

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad
  - Could we get a short summary of last week's Open Forum Summit.
  - Were IC vendors present to give feedback?
  - Could someone give a summary with that emphasis?
  - [Bob Ross, Brad Brim, and Walter Katz attended the Summit].

--------------------------
Call for patent disclosure:

- None

-------------
Review of ARs:

- None

-------------
New Discussion:  BIRD 147 Back-channel:

- Brad - Bob, want to give a summary?
- Arpad - Yes, nice to get an independent summary?
- Bob
  - Brad Brim presented "Back Channel Crossroads"
    - Overview of BIRD 147.
      - Relies on BCI file, which is used by Tx and Rx models and AMI files.
      - Potentially controlled by standards committees (SAS, Fibre Channel ...)
        - Using IBIS proposed syntax they produce the BCI protocol files.
  - SiSoft proposal describes co-optimization of SERDES channels using AMI.
    - No BCI file.
    - Protocol agnostic.
    - Info stored in Tx or Rx AMI file.
- Arpad - Were there any IC vendors there?  Did we get any feedback from them?
- Bob - There was some discussion.
  - David Banas from Altera and Xingdong Dai from Avago (LSI) were there.
- David Banas - [just joining the call at that time...]
  - I'll repeat what I said during the discussion.
  - If there is a way that my existing Tx .dlls can be used in co-optimization
    without changing the code, then that's a big plus for me.
- Arpad - Meaning use models that weren't designed for it originally?
- Ken - If you're going to pre-define what the Rx can send back...
    - The Tx will have to accept it.
- Walter - The Tx publishes its tap configuration to the EDA tool.
  - There are typically two ways to describe the taps.
  - Tx publishes the way they are described.
  - The Rx can determine what the optimal Tx equalization is.
    - Tell it to the EDA tool.
    - EDA tool translates that into how the Tx is reconfigured.
      - For example, it could call AMI_Close() and then re-call AMI_Init().
    - Rx just has to say what tap coefficients it wants Tx to use.
    - EDA tool can convert to the Tx's published way of configuring them.
- Arpad - Before we get into a technical discussion...
  - I want to summarize the current situation.
  - How are we going to continue?
  - It sounds like the summit didn't give us too much new info.
    - We did get David's preferences.
  - How do we decide what to do now?
- Walter - Did Michael Mirmak indicate how he was going to vote today?
- Arpad - Yes, it was not new information.
  - I'm not sure we had planned to have a vote today?
- Walter - I'm okay with deferring until next week.
  - Teraspeed, ANSYS, Altera and Mentor abstained last time.
  - Would they like to rehear the proposals from the summit?
- Arpad - We are familiar with them.  Let's try a different approach.
  - What are the complaints from the two parties about each others' proposals?
  - For example, David's point.
  - Just wondering if we can combine them into one super-proposal?
- Ken - I have two items.
  - BCI would involve interaction with standards bodies.
    - Need to figure out protocol specific content.
    - The same interaction would been needed if info is in Rx AMI file instead.
  - Reuse of existing models is enticing.  Can you clarify it?
    - If you're lucky enough to have already coded your existing Tx models
      the right way then you have a shot.
    - We have seen lots of models from different people that may not be so
      lucky and use that exact format.  They don't get the benefit?
- David - Maybe it bears some ferreting out.
  - I'm not sure myself how restrictive it might be.
- Ken - Even an existing model would need some function to publish data to Rx.
- David - Walter's proposal just adds parameters to reserved AMI sections.
- Walter - Synopsis thought having protocol agnostic Txs would be helpful.
  - There are two fundamental ways to specify Tx configuration.
    - Every Tx I know of has pre, main, and post cursor taps.
      - Maybe one or more than one pre or post.
    - The second issue is how does the AMI Model accept them?
      - Floating values from -1 to +1, or,
      - Integer values over some range (index).
    - Which is the parameter in the AMI file that represents each tap?
  - What I'm proposing are reserved AMI parameters that:
    - Communicate which are coefficient taps and which are indexed taps.
    - Define the min, max, and resolution.
  - Some vendors have a parameter for each tap, some don't.
  - Some expose the main tap, some don't.
  - There are various configurations.
    - They generally fall into one of several classifications.
    - Just define these several classes and cover 90% of cases.
    - We specify a way to do it.
    - It would be a straightforward change for those that don't already comply.
- Ken - AMI model specific parameters were supposed to be a black box.
  - Now we're going to say you may have to redo it if you didn't do it this way?
- Walter - We're not changing the model specific way for 90% of the models.
- Ambrish - We are now talking about adding multiple reserved parameters.
  - One describes the range of coefficients.
    - What if I want to provide a dynamic range where I gradually dial it back?
- Walter - Real world Silicon...
  - Every Tx I know of allows tap coefficients to be set with some granularity.
- Ambrish - Real world Silicon would never do "statistical" flow.
  - If, in the future, an IP vendor asks me, "How can I transmit a dynamic
    resolution to my Rx (depending on my power usage)?"  How do I do it?
- Walter - In that case, there is a desire for a private protocol.
  - Private protocol that does all of these exotic things is possible.
  - New reserved parameter in my proposal.
    - Called "Rx_Tx_Communication" (for example).
    - Whatever comes out of Rx GetWave() is passed to Tx and vice-versa.
    - Equivalent to your protocol specific section.
    - Protocol specific stuff doesn't really have to be in a BCI file.
  - But all of this would require recompilation of the .dll.
  - We're saying there's a lot you can do with any need for recompiling.
- Ambrish - How does the Rx understand what the Tx is sending and vice-versa?
- Walter - They agree on the protocol.
- Ambrish - That's not enough.
- Walter - Isn't the protocol what's defined in the BCI file?
  - What are the protocol specific parameters of the BCI file?
- Ambrish - They are what the Tx and Rx can talk about.
  - They can define other information to send each other.
- Walter - Isn't that limited to the protocol specific section of the BCI file?
  - I'm saying we can have a simple Tx and Rx that use the private protocol.
  - The protocol is defined in other documentation.
  - Just a reserved AMI parameter in Tx and Rx that says what they're using.
- Ambrish - Tx and Rx don't know how to communicate in that case.
  - Who would decide what gets passed between them?
- Walter - Who decides what is in the BCI file?
  - I think Brad said, "IBIS should not be in the business of BCI files."
- Brad - What I said is:
  - Just like an IBIS buffer, IBIS should define the format of the BCI file.
  - The content of an IBIS buffer or BCI file is up to the person defining it.
  - Existing protocols may not want to be bothered making the BCI file.
  - If they can't be bothered, IBIS should do it.
  - It's a paragraph, it's not rocket science.
  - I don't think we should be making standards out of others' standards.
- Walter - So there is no approval process for BCI files?
- Brad - If we publish it as an example it has to be approved.
- Walter - Is it part of a BIRD?
- Brad - It's the same thing for either alternative.
- Walter - Who decides what it will be for 802.3bj?
- Brad - That standards committee.
- Walter - What if they don't?
- Brad - You go and look it up.
- Kumar - We have to approve both, so it's not a distinguishing point.
- Ambrish - If the standards committee wants to make their own, IBIS doesn't do
            it for them.
- Walter - Have you gone to the 802.3 committee?
- Ambrish - No.
- Walter - I have, and they don't want any part of simulation.
- Ambrish - IBIS committee will do that if and when needed.
  - We'll have a standard BCI so the guy using it doesn't have to figure it out.
  - No assumptions and no confusion.
  - Only con is that every six months we need to meet and approve a BCI file.
- David - These two proposals sound very different.
  - Why are we forcing one or the other?
- Ambrish - Because back channel is what it's all about.
- David - No, it's about co-optimization.  Back channel is one solution.
  - Why can't we talk about Walter's scheme to get dumb old models to do
    co-optimization?
- Ambrish - We've been talking about back channel for years.
  - Now this co-optimization solution comes along.
  - We are talking about standard back channel communication people have wanted.
- Todd - Why don't we go with Walter's...
- Ambrish - Simple question is still, do we want back channel or not?
  - Do we want to go toward general co-optimization or not?
  - It's one and that same.
- Todd - Committee 101 says vote yes or no.
- Arpad - Someone said BIRD 147 is a subset of co-optimization.  Is that true?
- Walter - Yes, I believe BIRD 147 is a subset of what I'm proposing.
  - Our customers are adamant that they don't care how it gets optimized.
  - They just want to find the optimal solution.
  - I can understand why it's useful to see "how."
  - Our community typically has 20 channels with different vendors.
  - They want optimization now.
- Kumar - That is a red-herring.
  - There's no way to do it with an Init() only solution.
- Ambrish - You say your customers will only benefit from your solution.
  - That's not true.  We have statistical flow in our proposal.
- Walter - I'm not saying yours is wrong.
- Walter - Huawei has a back channel solution.
  - When they train it at low temp it doesn't work at high temp.
  - When they train it at high temp it works.
  - They have to do it via simulation and load the results.
- Kumar - At the same DesignCon a Xilinx paper showed that it worked.
  - There's no way an Init() only solution can do it.
- Walter - I've demonstrated that to a false statement.
  - It can be done in the Init() function.
- Arpad - Let's let Todd talk...
- Todd - This is a comment I made months ago that wasn't well received.
  - Co-optimization is simultaneously adjusting Tx and Rx for margin.
  - Whether back channel or anything else, it's optimizing for system margin.
  - I said to Kumar months ago, "you're trying to do it literally."
  - We have customers with 100s of channels who have to do the optimization
    ahead of time in simulation.
- Ambrish - Are we trying to make an accurate model?
  - Or, are we trying to help the system level guy who is using the model?
- Todd - I'm trying to make tools...
- Ambrish - No, we are not doing tools.
- Walter - Let me answer.
  - What you're proposing is a tool for the IC or IP vendor to develop or
    verify their model.
  - What I think IBIS should be doing is giving a tool for users to be able to
    co-optimize their channel.
  - If you look at what we agreed in 2007, main goal is to optimize the channel.
  - You're now proposing something to help design the IP.
- Ambrish - What is the problem we are trying to solve?
- Ken - I thought it was modeling.
- Kumar - Rx has a VGA and CTLE, each of which has hundreds of settings.
  - Tx settings will depend on what VGA and CTLE settle to.
  - That's how it really happens to make an accurate model.
- Arpad - If I want to attempt to answer Ambrish's question...
  - It depends on what we are trying to resolve.
  - If we're Intel we want alloys and crystal structures.  That's a model.
  - Next level up is a transistor level model.
  - The first is for process engineers.
  - The second is for chip designers.
  - I think our context here is more system level.
  - Don't care about crystal or transistor level.  Higher and Higher level.
  - Latest is AMI, we even got away from I/V curves.
  - Different level of abstraction.
- Kumar - This is not about abstraction.
  - It's very path dependent and real devices have path dependent optimization.
  - It's a question of real optimization.
- Arpad - I encourage people to keep working on this.
  - Lets work to try and make a decision for next week.
- Ambrish - Kumar and I can't make it the next two weeks.
- Arpad - Will someone from Cadence be here?
- Brad - I can be here.
- Arpad - We're at the top of the hour.  
  
-------------
Next meeting: 17 Jun 2014 12:00pm PT

-------------
IBIS Interconnect SPICE Wish List:

1) Simulator directives
